Scrum
introducción
Es un Framework principalmente usada en el desarrollo de software que se puede implementar con muchas herramientas que "automatizan" el proceso como Github. Aunque puede ser usada en cualquier desarrollo de proyectos. Es un framework de trabajo en Equipo, lo que quiere decir que se pueden trabajar desde 4 personas en adelante, Por ejemplo: Visual Code, tiene un equipo de 1461 persona en julio de 2021, divididas en 281 proyectos -características- del editor en más de 100 paises alrededor del mundo, usando como "guia de desarrollo" el RoadMap que tiene propositos tan ambiguos como
Continue on our journey to be the best editor for anyone who relies on accessibility features lo cual solo dice su predisposición al cambio, que es una de las características que veremos mas adelante.
tabla de contenidos
definiciones
- Metodología Ágil: es una forma de trabajar que abraza el cambio y la incertidumbre, es decir, se reacciona rápido al cambio sin sacrificar el proyecto. Por tanto, si hay algún cambio podemos reaccionar y adaptarnos de modo rápido. En la forma clasica de trabajo se planifica todo: cronogramas de entrega, diagramas de Gannt, presupuestos; tanto que la planificación consume mucho tiempo en la planificación o em modificar el plan si algo cambio, además las relaciones entre las personas son verticales (ver el sketch de humor) lo que impulsa la competencia, la cultura del premio y la información "falseada"(ver sketch de humor) al satisfacer un jefe o supervisor.
- Canvan:
- XP (eXtrem Programation):
- Proyecto:
- Metodología: es un conjunto de reglas, rígida
- Framework (caja de herramientas): es un marco de trabajo que SUGIERE, sin establecer reglas de si o si. Se puede por tanto, tomar lo necesario y adaptarlo al proyecto.
- Backlog: son las características (Requerimientos) que el proyecto debe tener. Aquí están TODOS, los requerimientos de TODO el proyecto, que se desagregaran según cada equipo que los desarrolle o según cada tiempo de un solo equipo. historia de usuario: son actividades propias de las dinámicas que el usuario quiere tener, Esto nos da la oportunidad de saber que y como desarrollamos alguna función. estas son actividades del backlog.
- tareas: diferentes actividades que debo completar para cada funcionalidad llamada historia de usuario
- sprint: es un periodo de tiempo (entre 1 y 4 semanas) para desarrollar características FUNCIONALES, el Scrum Master tiene como función calcular el numero de horas reales que deberá definir las tareas REALES que vamos a realizar en ese periodo de tiempo. Daily Scrum: decir que hicimos ayer, como haremos hoy y que dificultades tenemos. el Scrum Master gestiona para evitar que el desarrollador se distraiga en ello.
- sprint goal: es el objetivo que se debe desarrollar en un tiempo determinado. debe ser coherente y coordinado para ese periodo de tiempo y es determinado por el scrum team. Ese objetivo es lo que incrementa la funcionalidad de un producto.
roles
Lo primero que se necesita es entender los roles. Todo el equipo desempeña una función y esta debe ser clara desde el inicio. Por tanto entender los roles es una de las características mas importantes del FrameWork.
como características (skills) del equipo se espera:
- adaptabilidad al cambio
- comunicación
- escucha activa de características técnicas (especialmente para resolver conflictos o hacer pull request en git)
- sugerencias en diferentes campos
- no basta solo ser bueno técnicamente sino que se busca las capacidades blandas que guían el proceso.
- auto-organizados
- intuitivos
=> es ideal que el DevTeam sea entrevistado por el mismo DevTeam, no por alguien de recursos humanos.
Usuario(users):
es la persona que se impacta directamente con el uso de nuestra tecnología, Dispositivo, Software o Proyecto. Por Ejemplo: la persona que USA whatsApp, o la persona que USA facebook, etc. no hace parte del equipo pero esta en la visión global
customers(stakeholders, tomadores de decisiones):
son áreas o personas dentro de la organización que puede incidir en algún modo en el proyecto pero no directamente. Por ejemplo: contabilidad con recortes de presupuesto, mercadotécnica con métricas de compra de la aplicación, etc. Se comunican con el Producto Owner y no pertenecen directamente al equipo de Scrum, pero están en el panorama global.
Tomadores de decisiones(Cliente):
son las personas que buscan el desarrollo de un producto, característica, tecnología o proyecto. Ellos contactan con áreas como Ventas, Soporte (stakeholders) y en nuestro caso con el Product Owner. Ellos a su vez pueden tener sus clientes (Por ejemplo: nuestro cliente es UBER pero SUS clientes son las personas que toman el carro) que para nosotros serán los usuarios. No son parte del equipo Scrum
Product Owner(PO):
es el contacto principal entre el cliente y el grupo de desarrollo. A veces llamado cliente interno, sus funciones principales son "traducir" (tarea muy difícil como retratan con humor en este sketch) y ayuda a priorizar las tareas del cliente externo ayudándole a entender que se debe enfocar primero. Las características esperadas en la aplicación o tecnología (Backlog) o la revisión de las características ya estructuradas (review). Se espera como características de un PO(features) la comunicación, las métricas, el punto de vista de stakeholders y resuelve o consigue la información necesaria para el DevTeam( no tiene que tener toda la información pero si conseguir la información), además del conocimiento tanto de administración como de programación por lo que la carrera ideal es un ingeniero industrial, pero puede ser un psicólogo, o un administrador de empresas. No es necesario que sepa Scrum, es deseable pero no obligatorio. Si el producto falla es responsabilidad del PO, por ello debe priorizar claramente los objetivos a conseguir.
- prioriza con base en lo que mejor le convenga a la organización
- evita la invalidación de personas superiores, para esto es importante que tenga legitimidad en la organización para poder decir que se hace o que no sin interferencia de un superior. debería (fuertemente) solo haber un PO.
- debe ser orientado al logro, es la voz del cliente, maximiza la gestión del producto, define el producto mínimo viable.
- que no es:
- no es responsable del estado
- no desarrolla el software
- no supervisa el DevTeam
- no cambia los recursos
- no asigna los recurso
- no hace las reuniones diarias.
Scrum Master(scrum):
primera claridad no es el Jefe, no es un gestor, ni un líder. Es un facilitador que hace parte del equipo, que dirige las ceremonias de Scrum, y ayuda al uso de la metodología en el desarrollo. Estima el tiempo de cada tarea y vigila los tiempos, define los Sprint. Puede darse el caso que el Scrum Master sea también un Development, No debe darse el caso que un Scrum Master sea a su vez Product Owner.
- es un Servant Leader (Líder al servicio del equipo, no dirige, no gestiona) ayuda a ver como comunicarse con el DevTeam.
- no es:
- dueño del producto
- no es líder técnico, es miembro del equipo.
- no mide el impacto del producto
- no asigna tareas
- no habla en los dailys
- y no hace el backlog o productback
DevTeam:
son los profesionales que se encargan de crear el producto, se definen principalmente por sus capacidades técnicas especializadas (backend, frontend, Datase Administration, Fullstack, devOps, el conocimiento de un lenguaje especifico). En el caso que el proyecto no sea de software pues serán los especialistas en cada rama. deben saber Scrum, pero no necesariamente ser expertos en el Frame. no hay un lider de ellos, el equipo es Autoorganizado y autogestionado y son quienes deciden que tecnologia se debe usar para cada una de los desarrollos. Como se asume que cada uno es experto en el area no necesita una guía sino que su cncepto es ley en su campo. Al tener que hacer una API o espacio de comunicación con otra area se deben llegar a concensos, esta tarea la facilita Git a través de sus conlifct developers y de sus request pull. Ellos deciden que tareas deciden hacer porque estan AUTOMOTIVADOS. Estas tareas en git se mueven desde los projects y sus columnas se definen en grupo pero se sugieren (toDo, Doing y Done). EN SCRUM NO HAY ROLES COMO TESTER, DEVELOPMENT, ETC. ESTO VIENE DEL WATERFALL.
- deben tener el chip de lo incremental. No existe un PRODUCTO FINAL, sino un incremento. ejemplo: el usuario quiere moverse en un vehículo:
- opciones de cascada: crear partes del vehículo, primero las ruedas, luego la carrocería, luego los asientos. es decir características que requieren de una anterior para gestionarse
- opciones de Scrum: primero un monopatín, luego una bicicleta, luego una moto, luego un carro. es decir creaciones independientes que pueden gestionarse con otras o ser independientes.
- si
- que no tienen como función:
- no definen tareas, historias de usuario, actividades, hitos, etc.
- no hablan con el cliente directamente a menos que sea necesario.
- no definen el producto
- no hacen los requerimientos
scrum team: Product Owner + Scrum Master + DevTeam
- cualquier refinamiento debe hacerse por medio del PO. Si se requiere una reunión con el cliente o el usuario se gestiona por el PO.
- se puede renunciar siempre después de finalizar el Sprint. por eso se busca compromiso.
erDiagram
USER ||--|{ CUSTOMERS : "contacta a"
CUSTOMERS ||--|{ PRODUCT_OWNER : "asignan un"
PRODUCT_OWNER ||--o{ SCRUMTEAM : "integra un"
SCRUMTEAM }|..|{ SCRUMMASTER : "donde hay un"
valores
experiencia
se entiende como experiencia la toma de decisiones basada en decisiones iguales anteriores o en decisiones parecidas, esto procede del concepto matemático de regresión lineal y no es garantía que vaya a garantizar el éxito. Por ejemplo: Hoy Jueves llovió en la tarde, de manera similar que el Lunes Martes y Miércoles; lo que hace probable que mañana Viernes llueva. Pero no se garantiza que ocurra de ese modo.
Revision
Al pensar la metodología que el cambio es una constante y se debe preparar para ello, la revisión de los artefactos debe ser continua. Esto permite además de estar atento a cualquier cambio tener claro el objetivo a lograr. Una duda continua es qué tan frecuente debe ser continua, o cada cuánto tiempo es continua. la respuesta es depende:
- del mismo equipo de trabajo
- del proyecto y la variabilidad que tenga
- del ritmo de trabajo del equipo la regla general es tanto como se pueda, sin interferir con el desarrollo del objetivo.
Adaptación
Sabemos que las metodologías ágiles ven el cambio como una constante. Pues esa constante es la guiá el trabajo, pero para evitar cambios abruptos se establecen marcos de referencia para cambios. es decir, se detectan las variaciones y se miden dentro de limites de tolerancia permitidos. Sí están dentro el cambio no afecta el proyecto. si están fuera hay que modificar algo. Los tester deben estar continuamente monitoreando y haciendo pruebas sobre el producto desarrollado, de allí que tener el código centralizado como en Github permita no solo el trabajo en el desarrollo de características sino en el mismo test continuo.
Transparencia
el acceso a la información no debe ser en punto del desarrollo, sino que debe ser continuo, para todo interesado en el proyecto, en todo momento, en toda etapa. Todo lo que se desarrolle debe tener un responsable y un backup. para esto es necesario el desarrollo de patrones comunes altamente difundidos y comunicados con el equipo. Este es el punto central del uso de Git y de algún hub de código como github.
Git se convierte en la herramienta central del proceso Scrum al integrar el Scrum Board o tablero de actividades, la documentación o wiki, el código o source y gestionar tanto el acceso como las métricas y estadísticas del equipo. desplegar pruebas y generar tanto el backup como el front code constantemente por medio de las ramas o branch.
Por supuesto que no gestiona la transparencia de un equipo, pero si de su información, y esto facilita tener en cuenta esa comunicación con datos reales.
eventos
los eventos en sprint son las dinámicas que se llevan a cabo en cada periodo para:
- estar al tanto de cambios o revisar el avance hacia el logro
- ver que hubo de bueno y como mejorar en siguientes trabajos y proyectos
- revisar el desarrollo de actividades
- informar sobre avances o problemas que hay.
Sprint
el Sprint es el proceso central que contiene otros procesos, en Github lo llaman Milestone. Puede durar mínimo una semana y un máximo de 4 Semanas, en las cuales se debe entregar un producto terminado, probado y documentado. Que debe funcionar independientemente de los Sprints futuros, pero puede funcionar como incremento de los Sprints pasados.
Cada Sprint tiene como objetivo una característica (feature) que desarrollar. Y en cada Sprint se desarrollan el resto de eventos que dan cuenta del avance del proyecto en general y de la característica en particular. Estos eventos se llaman ceremonias y son:
- Sprint planing
- Daily Scrums
- Sprint Review
- Sprint Retrospective
cada evento da cuenta de una planeación o evaluación del Sprint Goal (objetivo del Sprint).
un Sprint no es / no se hace:
- una reunión
- un conjunto de reuniones
- una fecha fija
- no se cambian objetivos
- no se mueven [desarrollos, documentación, pruebas]
en un sprint es / se hace:
- desarrollar caracteristica del producto
- aprender
- medir
- hablar con el Product Owner para clarificar actividades del objetivo o tarea
se puede cancelar un Sprint???
en caso de fuerza mayor, el Product Owner y solo el Product Owner puede cancelar un Sprint. Se consideran casos de fuerza mayor aquellos donde el producto deja de tener sentido en el contexto actual. No se considera un caso de fuerza mayor el hecho que un cliente no tenga dinero de respaldo ya que la mayoria de empresas de desarrollo cobran por adelantado.
En caso de cancelación las ceremonias se mantienen, haciendo tanto el review como el retrospective.
Sprint Planing (Sprint Meeting)
Una vez el Product Owner haya definido el objetivo mínimo realizable y tenga las historias de usuario, se reúne el equipo para planificar el sprint. Esta ceremonia tiene una duración máxima de 8 horas y su objetivo es la planificación y distribución del periodo de tiempo en el que se desarrollará la Feature (característica) cualquier otra característica será contemplada en otro Planing. Asegurarse de eso es trabajo del Scrum Master. Las dos preguntas que guían esta ceremonia son:
- que puedo desarrollar en [inserte el tiempo del Sprint] ?
- como puedo desarrollar [inserte aqui la caracteristica a desarrollar] en [inserte el tiempo del Sprint] ?
que podemos desarrollar?
en esta pregunta el Product Owner pone a discusión la característica o funcionalidad a desarrollar en el sprint. La característica viene acompañada de sus respectivas historias de usuario (requerimientos del cliente) y del Backlog (requeriminetos totales) para dar una perspectiva global. y aquí se divide en dos posibilidades
primero, si es el primer sprint del desarrollo o el equipo es nuevo, o alguno de sus miembros es nuevo, se discute los proyectos anteriores (sprints) en caso de haberlos, se estima la capacidad de trabajo (stars) y se evalua la feature presente.
segundo, si es un sprint adicional, con el mismo equipo de desarrollo, en el mismo proyecto; se evaluá el último sprint en cuanto a características técnicas y tecnologías, la velocidad del equipo (medida en características - en git se usan los issues- o lineas de codigo - en github pull request-) y la gestión de dificultad del equipo (medidas en puntos(stars)).
una vez esta establecido el Sprint Goal (objetivo) se crea un nuevo scrum board (en github se hace desde projects) y se establece como meta a lograr.
como puedo desarrollarlo?
cuando el Sprint Goal esta listo y nuestro tablero creado, se empieza a enumerar las tareas y tecnologías que se usaran para poder lograr ese objetivo. Esta dinámica es más como una lluvia de idea basada en la experiencia técnica. En caso de haber dos tecnologías o caminos que resuelvan lo mismo es el equipo quien debe decidir como resolver el conflicto. usualmente después de escuchar las ventajas y desventajas técnicas de cada tecnología.
con la lista de actividades calculamos el tiempo o dificultad (medida en estrellas o puntos) y debería arrojarnos como tiempo base menos de un día de trabajo. si es más que eso se puede continuar subdiviendo en tareas más simples hasta lograr periodos menores a un día o periodo de trabajo.
A partir de allí el equipo se auto-organiza para empezar a completar cada tarea según sus habilidades o intereses,esto parte de mantener el equipo altamente motivado. Estas tareas quedan consignadas en un sistema llamado un Sprint Backlog, que serán los "requerimientos" de ese Sprint.
En este punto el trabajo del Product Owner es aclarar cada pregunta del equipo, si no es posible eso comprometerse en un tiempo razonable a conseguir y gestionar la información y recursos. En caso de evidenciar un exceso de trabajo deberán renegociar con el Product Owner, del mismo modo que al tener poco.
Al finalizar la reunión debe ser claro para todos que tareas, que tecnologías y que tiempos van a usar para el desarrollo del Goal. Resumiendo el Planing es el mapa para encontrar el tesoro.
scrum Daily
es una reunión diaria del scrum team con un máximo de 15 minutos que tiene como objetivo sincronizar las actividades del equipo para un periodo máximo de 24 horas o un periodo de trabajo. para hacer esta sincronización se revisa el avance desde el último scrum daily y se proyecta hasta el siguiente. cada miembro del equipo debe responder:
- que hice ayer que acerco al equipo al goal?
- que haré hoy que acrque al equipo al goal?
- que me impide ayudar a mi equipo a acercarse al goal?
el Product Owner y el Scrum Master deben estar atentos a esta última duda para poder gestionar los recursos y ayudar a lograr ese Goal (objetivo) en el tiempo del sprint. Sin embargo el Equipo de desarrollo es el responsable de la reunión, que quiere decir que debe llevarse a cabo con o sin Scrum Master y Product Owner.
Sprint Review
al finalizar el Sprint se ejecuta una nueva ceremonia con todo el Scrum Team para revisar el incremento del Goal de ese Sprint. Es una reunión con un máximo de 4 horas y se evalua:
- si el Sprint Backlog se logro completo o que cambios se requirieron
- que problemas aparecieron y como se resolvieron
- presentan la documentanción del Sprint como guía para los no programadores
- se deja evidencia de necesidades, procesos inconclusos o problemas para futuros sprints o futuros equipos.
- se revisan las tecnologías de desarrollo de la caracteristica
- se revisan fechas de liberacion de la RC (Release Candidate) o de publicación del producto
- se perfilan pruebas no funcionales o de caja negra (pruebas de estres, pruebas de perfiles de usuario, pruebas de seguridad, pruebas de resistencia, etc.) las pruebas unitarias y de implementación ya debieron ser realizadas y su estado debe ser exitoso para considerarse un producto terminado
- se revisa el Backlog (requerimientos generales) para ver si hay alguna modificación antes de los siguientes sprints.
Resumiendo en esta ceremonia nos enfocamos en evaluar el objetivo y sus caracteristicas técnicas. el desarrollo conceptual y factico del producto y las oprtunidades de negocio, de tecnologías y de variación que existen para el PRODUCTO. No es una reunión de funcionamiento del equipo, de las personas o de las relaciones interpersonales.
Sprint Retrospective
es una reunión del Scrum Team de maximo 3 horas que se realiza como finalización del Sprint. se enfoca en evaluar las relaciones interpersonales, el trabajo en equipo, las metricas de manejo de dificultad y tiempos, las herramientas usadas para la gestión. no evalua una persona sino el conjunto de ellas para esto se usa como insumo la evidencia del restrospective anterior que determinaria que habia que mejorar y se evalua si se cumplio o que hizo falta para lograrlo; se deja evidencia de lo que se esta haciendo bien y se crea el plan de mejora para la siguiente meta de trabajo en equipo.
En resumen esta reunión se enfoca en las habilidades blandas del trabajo en equipo para mejorar como grupo, NUNCA SE EVALUA UNA PERSONA SOLA. Al terminarlo se da por finalizado el Sprint.
Artifacts
son herramientas de Scrum que nos permiten revisar los cambios y adaptarnos a ellos de modo veloz.
Backlog (Product Backlog)
es una lista ordenada realizada por el Producto Owner, con los stakeholders, los clientes, los usuarios, etc. donde están los requerimientos para el desarrollo de una aplicación, tecnología o proyecto.
la lista al igual que todo el resto de las dinamicas de Scrum puede cambiar y sus primeras versiones solo muestran las necesidades iniciales e inmediatas sobre un producto, tecnologia o aplicación. A diferencia de las metodologias en cascada o tradicionales diferentes requerimientos no son necesariamente diferentes productos, sino que son incrementos del mismo producto. Por ejemplo: el navegador google Chrome se libera cada 6 semanas, y su lista de requerimientos (RoadMap) es variable cada 6 meses dependiendo de la visión tecnologica de alphabet, lla casa matriz de google.
esto ocurre porque en la medida que los usuarios de un producto se "adueñan" de el piden o implementan caracteristicas diferentes que al principio se conocen como add-ons (Añadidos o extensiones, de ahí que sena tan populares en casi todas las nuevas aplicaciones) y que posteriormente se implementan como parte del nucleo para satisfacer los usuarios. Esto no significa que sea otro producto sino que el CAMBIO del mercado obligo a incrementar el valor del mismo desde la programación de la aplicación.
este Artefacto es responsabilidad y de manejor exclusivo de Product Owner.
Sprint Backlog
de la lista general de requeriminetos (Backlog) se seleccionan algunas tareas para cada sprint (puede ser solo una); despues de esa selección y con una ceremonia de planing se crea un plan para lograr esas acciones, y posteriormente se crean unas actividades que permiten evidenciar commo se ejecutará cada cosa. a este recurso le llamamos Sprint Backlog.
Este artifact debe ser lo suficientemente granular para que en cada Scrum daily podamos saber como vamos avanzando hacia el objetivo. Este artefacto es propiedad y uso exclusivo del DevTeam aunque puede recibor *sugerencias" del resto del Scrum Team.
el Sprint Backlog es generalmente registrado en un Scrum board (en el caso de Git en projects) y permite ver la movilidad y cambio al pasar una tarea de planeada a ejecutada.
TODO
- simulador de fundamentos de scrum
- fundamentos de scrum
- simulador de Scrum Master
- examen oficial de Scrum Master